home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 317 < prev    next >
Internet Message Format  |  1996-08-06  |  3KB
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.lang.c,comp.std.c
  4. Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
  5. Date: Wed, 07 Feb 96 12:58:40 GMT
  6. Organization: none
  7. Message-ID: <823697920snz@genesis.demon.co.uk>
  8. References: <30C40F77.53B5@swsbbs.com> <SPENCER.96Jan22113215@zorgon.ERA.COM> <KANZE.96Feb2133347@slsvewt.lts.sel.alcatel.de> <DM5urJ.Aq5@mv.mv.com>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <DM5urJ.Aq5@mv.mv.com> ENGR@GSSI.MV.COM "Michael Furman" writes:
  15.  
  16. >In article <KANZE.96Feb2133347@slsvewt.lts.sel.alcatel.de>, 
  17. >kanze@lts.sel.alcatel.de says...
  18. >>  ..................................
  19. >>Note that implementations *are* allowed to offer extensions, and
  20. >>define undefined behavior in an implementation specific manner.  An
  21. >>implementation which defines, for example, that writing to the address
  22. >>0 clears the screen, is perfectly legal.  If you write code uniquely
  23. >>for that implementation, and you have to clear the screen, you will
  24. >>dereference a null pointer.  If this is the only way of clearing the
  25. >>screen on said implementation, and your application requires clearing
  26. >>the screen, you will write code dereferencing a null pointer.
  27. >>
  28. >>That doesn't make such code any less undefined with regards to the
  29. >>standard.
  30. >
  31. >I can not say that I agree ... Of cause some implementation may define
  32. >any "undefined" behavior. But I still see two very different cases -
  33. >a) when construction assumed as incorrect, like dereferinsing wrong
  34. >pointer and when it has clear purpose, but exect meaning can not be
  35. >defined portable (like "asm").
  36.  
  37. Some compilers support a fortran keyword but, like asm, it is not defined
  38. by the standard. It is up to you to define the environment you want to
  39. work in. If you want to work in a pure ANSI C environment then asm, fortran
  40. and numerous other common extensions have no meaning at all and simply
  41. result in undefined behaviour. If you want to use them define an environment
  42. in which they have meaning. Most people don't write strict ANSI C code. 
  43. However it is useful to separate what is and isn't strict ANSI C code and use
  44. ANSI C whenever possible since that makes porting *much* easier.
  45.  
  46. >What do you think about code with "asm" statements. Is it "less undefined" 
  47.  
  48. As far as ANSI C is concerned it is equally as undefined as any other form
  49. of undefined behaviour. However there's more to the world than ANSI C.
  50.  
  51. asm is nothing special in ANSI C hence can be used as an ordinary identifier.
  52. So a compiler that treats asm specially is unlikely to be conforming i.e.
  53. behaves differently to what the standard mandates. This can be fixed but
  54. making asm only 'special' on the inclusion of a non-standard header file.
  55.  
  56. >and if not - what is the sense and reason of including
  57. >"asm" keyword in the standard?
  58.  
  59. None because it isn't! :-)
  60.  
  61. -- 
  62. -----------------------------------------
  63. Lawrence Kirby | fred@genesis.demon.co.uk
  64. Wilts, England | 70734.126@compuserve.com
  65. -----------------------------------------
  66.